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Description 

The invention relates to a method and a system for mutual exclusive control of resources sequentially avail- 
able In an event driven process. The sequentially available resources to be controlled are resources that are 
5 controlled by a computer, a programmable logic controller or the like. 

Important subjects in the recent computer technology are multitasking, multiprocessing and distributed 
processing. To implement these techniques, it is necessary to share a resource between several tasks or proc- 
esses during parallel execution of a plurality of tasks or processes. Such a resource is called a shared resource, 
which includes, for example, various peripheral devices, disks, memories, communication lines, programs, and 
10 data. A shared resource that is allowed to be appropriated to one task or process at a time is called a critical 
resource. 

The problem of mutual exclusive control of resource in an event driven process arises when event driven 
processes are executed in parallel, and they use the shared resource. The mutual exclusive resource control 
is a mechanism for assuring that the shared resource will be held by at most one process. An area which holds 

IS a shared resource in the processes executed in parallel is called a critical section. It is a problem of sharing a 
resource when a plurality of tasks are executed in parallel, and is presented as a problem of interprocess com- 
municatton and synchronisation. To solve it, conventionally, various techniques are proposed, and it is analysed 
by a model for use in a system. The synchronisation problem includes the mutual exclusion problem, the pro- 
ducer consumer problem, the dining philosopher problem, or the readers/writers problem. 

20 At present, there is no way of solving a problem of the mutual exclusive resource control between a plurality 

of processes, which is important in implementing a parallel execution system, but a programmer carefully 
writes, by using semaphores. Thus, when a programmer writes a program executing in parallel, or when an 
operator executes a program undersuch environment, attention must be always payed to resource assignment 
It is a burden for the programmer or the operator. 

25 An example of programming using semaphores will be explained below. Now. it is assumed that there are 

three flows of event driven processes Gi, G2 and G3 schematically shown in Figure 2. In the first flow of process 
Gi, tasks pi and P2 are sequentially processed. After the task pi is executed while using shared resources A 
and C, the task p2 is executed while using shared resources B and C. 

In the second flow of process G2, a task P3 is executed. The task P3 is executed while using the shared 

30 resources A. B and C. In the third flow of process G3 tasks P4 and P5 are executed in parallel. The task P4 is 
executed while using the shared resources A and C, and the task P5 is simultaneously executed while using 
the shared resources B and C. ti - ty indicate start or end points of the tasks. It is assumed that, among the 
resources appearing in Figure 2, critical resources are A and B, and that the critical resource A is a robot 2. 
while the critical resource B is a robot 1 . 

35 At present, in most cases, programming is performed on each critical resource (controller for production 

apparatus in a manufacturing process, or a computer in a network system), which requires a program on each 
critical resource and a program for controlling them. An example of this is shown in Figure 3. Figure 3A is a 
program for controlling the entire system. Figure 3B being a program for the robot 1 , Figure 3C being a program 
for the robot 2. 

40 Here, syntax for describing the parallel execution is as follows: 

cobegin 

P1; 
P2 

coend 

45 wherein P1 and P2 are tasks executed in parallel. 

In addition, syntax for describing a critical section is as follows: 
with R do 

begin 

S 

50 end 

wherein R is a unique name for a critical resource to be mutually excluded, and S is a critical sectfon to be 
mutually excluded. In this case, R is a semaphore. 

In Figure 3A, R(p) is a program for a robot indicated in Figures SB and 3C, respectively. When a parameter 
p is passed to R, the program for R executes only the task for p. 

55 The syntax for describing the critical section and its mechanism, as well as the syntax for describing the 

parallel execution and its mechanism are not supplied to the programmer generally, so that it becomes respon- 
sibility of the programmer to write the descriptk>n, to produce its mechanism, and to debug the mutual exclusive 
control. 
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Now. there is one technique called Petri-Net that is widely used for nrKxlelling of a system. Features of the 
Petri-Netare parallelism orsimultaneousness and asynchronism. Its execution may be considered to be a ser- 
ies of discrete events, and the timing when an event occurs is indefinite. It has been attempted to utilise these 
features and the execution form for the event driven control. The Petri-Net is also used in simulation of a parallel 
5 execution system (a computer model, or a manufacturing process) by noticing its good mathematical analysis 
characteristics and high modelling capability. 

Now, the overview of Petri-Net will be explained. 

The Petri-Net consists of four components: a place, a transition, an arc. and a token. The place indicates 
an event the transition indicates a condition, the arc indicates a path, and the token indicates a state. The 

10 token moves in the arc between the places according to the conditton of the transition, and causes an event 
corresponding to the place. 

Figure 4 shows an example of executton of the Petri-Net. In this example, explanation is made by using 
a transition T = {te. tt. tj, place P = {P^, Py. PJ. and a token. First, if there is no token in P^, ta generates a 
token and places it in P, (Figure 4A). If P^ has a token, and Py and do not have a token, tb transfers the 

15 token to Py and P, (Figure 4B). Py and P^ have a token, tc takes out and erases the token. For the details of 
the Petri-Net, reference should be made to Peterson. J. L. "Petri Net Theory and the Modelling of Systems." 
Prentice-Hall Inc., 1981. 

Recently, a system is proposed wherein a programmer describes a flow of processes as shown in Figures 
2 or Figure 4 by using a graphic editor, and converts it Into codes to create a program for controlling the entire 

20 system so that, while instructing start of the task or receiving a termination signal, the token is automatically 
transferred according to these signals based on the program in execution. For example, reference should be 
made to Hasegawa, K. and Takahashi, K.. "MFG (Mark Flow Graph)-Based Programmable Controller and its 
Application to FMS." Proceedings of the International Conference on System Engineering, pp. 306 - 311. 1984. 
Also, reference should be made the document by K. Hasegawa et al.: 'MFG (Mark flow graph)- based pro- 

25 grammable controller and its application to FMS'. which shows the use of a Mark Flow Graph (MFG) deduced 
from the Petri net Antarked flow graph is stored in a programmable controller and is used in a control system 
having among its properties; asynchronism and concunrency. In the nodes of the graph, called boxes and in- 
dicating the condition of a system element are stored marks or tokens to control the system state. A transition 
is uniting are or more input boxes with one or more output boxes. The firing of a transition to another system 

30 state is perfonmed only when all input boxes have marks therein. 

However, none of these conventional control systems takes the mutual exclusive control into considera- 
tion. 

Although it is for an aspect in modelling rather than programming, modelling of the mutual exclusive control 
is perfonmed by creating a place corresponding to an empty state of resource (empty place), connecting it to 

35 a place of a task using that resource to establish a critical section. In this case, it utilises storability that is an 
important characteristic of the Petri-Net The empty place contains a token as an initial marking, and always 
contains a token when a resource is not used. When a process is in a critfcal section, and using a resource, 
the empty place does not contain a token. If another process attempts to enter the critical section for using 
the same resource, it cannot be executed because the empty place does not contain a token and a fire condition 

40 is not satisfied. Execution of another process is caused to wait until the process using the resource ends, re- 
leases the resource, and returns the token to the empty place. 

Figure 5 shows an example of such modelling. Place m indicates authorisation to enter a critical section. 
When a process wants to enter the critical section, it supplies a token to p^ or P2 issuing a sign that indicates 
its wish to enter the critical section, and waits for a sign allowing entrance into the critical section or the token 

45 of m to access the critical section, if both processes want to enter the critical section, transitions t, and tz cause 
contention, and only one of them can be fired. Fire oft, disables that of t2, and the process 2 is caused to wait 
until the process 1 completes the critical section and returns the token to m. 

Then, can the mutual exclusive control be easily implemented if a graph having empty places for critical 
resources is created, and converted into codes so as to create a control program for the entire system taking 

so the mutual exclusive control into consideration, and the token is automatically transferred as the system de- 
scribed in the above reference (2)? Unfortunately, the answer is "No." The reason is described below. 

(1) First empty places must be incorporated in the Petri-Net If a programmer incorporates the empty plac- 
es in a suitable location in the Petri-Net while paying attention to critical resources, his effort will be equiv- 
alent to programming using semaphores. The creation of the Petri-Net becomes very difficult for a slightly 

55 complicated case as Figure 6 compared with a simple case as Figure 5 aside. 

(2) In execution, a user must first distinguish the empty places (resource places) from task places, and 
then place initial tokens in all empty places. This imposes a significant burden on the user. 

(3) A deadlock may be caused from the representation of the Petri-Net itself. 
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Now, it is explained by taking Figure 6 as an example. It is assumed that the current state is as shown in 
Figure 6A. That is, the tasks Pi and P4 are being executed, and the resources Px and Py are empty. The resource 
Px is used by the tasks P2. P3 and Pg. The resource Py is used by the tasks P3, P5 and P©, 

If the state is as shown In Figure 6A, then it is dear that the control system can start the execution of the 

5 tasks P2 and P5. Thus, t^ and t4 transfers the tokens to P2 and Pg, respectively. Here, it should be noted that 
because the representation as shown in Figure 5 or Figure 6 connects each end of the critical section to the 
empty place of the resource, the token is never transferred to the empty place of Px until the execution of the 
task P3 following the task P2 is completed, and that, similarly, the token is never transfenred to the empty place 
of Py until the execution of the task Pe following the task P5 is completed. Figure 6B shows the positions of the 

10 tokens after starting the execution of the tasks P2 and P5. Now. the control system cannot start the execution 
of the task P3 even if the executton of the task P2 is completed because there is no token in the empty place 
of Py. A token is never returned to the empty place of Px unless the executton of the task P3 is started. Thus, 
the executton of the task P© is also not started. In this way. the transitions tj and ts cannot fire and thus causes 
a deadlock. In the Petri-Net. transitions that cannot fire or their set is called a deadlock. 

15 In a mathenratical representation. G = (P. T, O) where G is the Petri-Net structure. P = {P,. P2, ... Pm) is a 

set of places and M > O, and T = (Ti, T2, ... T J is a set of transitions and L > 1 . The set of places and the set 
of transitions are disjoint, and P n T = <|>. I : P — ► T is an input function from a place to a transition, O : T P 
is an output function from a transition to a place. A Petri-Net structure to which a marking \l for assignment 
of a token to a place is added is called a marked Petri-Net The token exists only in the place, and fire of the 

20 transition controls execution. Fire of the transition transfers a token from an input place to an output place. 
The Petri-Net structure is dual in the graph theory. The concept of dual of a graph is not utilised in the marked 
Petri-Net because the dual of a graph is difficult to define. 

A method for mutual exclusive resource control according to the present invention comprises steps of: 

(a) generating a graph and retaining the graph in a storage apparatus, the graph comprising nodes to which 
25 tasks included in a process flow and a critical resource, which may be appropriated by at least one of the 

tasks, are mapped, nodes of tasks executed sequentially being arranged in series, nodes of tasks executed 
in parallel being arranged in parallel with each other, a node of critical resource being arranged in parallel 
with every node of the task that may appropriate the critical resource; and 

(b) each time a signal for t)eginning execution of a task is transmitted, generating a token in the node of 
30 the task and the critical resource node in parallel therewith; and 

(c) when the end of execution of the preceding task in the process flow is detected, referring to said graph; 
and causing the transmission of a signal for beginning execution of the immediately succeeding tasks to 
wait while a token is assigned to at least one of the immediately succeeding task node and the critical re- 
source node arranged in parallel therewith. 

35 It is preferable, in the step (a), to provide nodes of the gates in the graph at a location where nodes of the 

tasks t>eing sequentially executed are connected; 

in the step (b). every time the completion of the execution of a task is detected, to renrove the node of 
the task and a token assigning to a critical resource that is arranged in parallel to that node; and 

when completion of execution is detected for tasks corresponding to every task node arranged imme- 
40 diately before a gate node, to generate a token in the gate node, and then, while a token is assigned to any 
one of a node for a succeeding task arranged immediately after the gate node or a node of a critical resource 
arranged in parallel with it. to cause the transmission of a signal for beginning the execution of the succeeding 
task to wart by referring to the graph; and to 

remove the token from the gate node after the transmission of the signal for beginning the execution 
45 of the succeeding task. 

A preferred system for mutual exclusive resource control according to the invention comprises a storage 
device holding a graph that has tasks contained in a flow of process and nodes corresponding to a critical re- 
source capable of being exclusively appropriated by any of the tasks, and in which nodes of tasks being se- 
quentially executed are arranged in serial, nodes of the tasks being executed in parallel being arranged in par- 
se allel with each other, a node of a gate being arranged at a location connecting the nodes of the tasks with each 
other, a node of a critical resource being arranged in parallel with the nodes of all tasks capable of exclusively 
occupying the critical resource; 

a means for generating tokens in a node of the task in the graph and in a node of a critical resource 
arranged in parallel with the node every time a task beginning signal is transmitted; 
55 a means for removing the tokens assigning to the node of the task and to the node of the critical resource 

arranged parallel with the node every time the end of the executron of the task is detected; 

when a completion of executton is detected for tasks corresponding to every task node arranged im- 
mediately before a gate node, generating a token in the gate node, and then, while a token exists in any one 
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of a node for a succeeding task arranged immediately after the gate node or a node of a crftical resource ar- 
ranged in paraliel with it causing the transmission of a signal for beginning the execution of the succeeding 
task to wait by referring to the graph; and 

a means for removing the token from the gate node after the signal for beginning the succeeding task 
5 is transmitted. 

An embodiment of the invention will now be described in detail with reference to the following figures. 
Figure 1 is a system configuration of an embodiment according to the Invention. 
Figure 2 Is a schematic view of the flow of the process. 

Figures 3A, 3B and 3C are diagrams illustrating the descriptk)n of an example of a mutual exclusive control 

10 program according to the prior art 

Figure 4 is a diagram illustrating an example of execution of a Petri-Net 
Figure 5 is a diagram illustrating a nKKlel of mutual exclusive control employing the Petri-Net 
Figure 6A and 6B are diagran^ illustrating a deadlock that would occur if a conventtonal Petri-Net were 
executed to perfonm the mutual exclusive control. 

IS Figure 7 is a diagram illustrating a process flow graph. 

Figure 8 is a diagram illustrating a process flow graph and a task program. 
Figure 9 is a diagram illustrating a resource management graph. 

Figura 10 is a flowchart of processing procedures for generating a resource management graph. 

Figure 11 is a flowchart of processing procedures for generating a process resource graph. 
20 Figure 12 is a diagram illustrating a process resource graph. 

Figure 13 is a flowchart of processing procedures for generating a union graph of a program flow graph 
and a resource management graph. 

Figure 14 is a diagram illustrating a flow of process that causes a deadlock. 

Figure 15 is a diagram showing a union graph representation of the contents of Figure 14. 
25 Figures 18A, 16B, 16C, 16D, 16E. 16F are diagrams showing an example of execution of the process re- 

source graph of Figure 12. 

Figure 1 7 is a diagram showing an example of hardware configuration of a mutual exclusive control system. 

Figure 18 is a diagram showing the process resource graph corresponding to Figure 6. 

Figures 19A. 19B, 19C and 19D are diagranrts showing an example of execution of the process resource 
30 graph of Figure 1 8. 

Figure 1 is a system configuratton of an embodiment of the invention. Now, steps SI - S8 in the figure are 
described in order. 



(a) Creation of a process flow graph (step S1) 

35 

A user creates a process flow graph representing an event driven process with a task as a unit of process. 
The created process flow graph is equivalent to a restricted Petri-Net graph with a safe and active nature (with- 
out multibranch nor self loop). Refer to the "Mathematical Representation" for the definition of the process flow 
graph. 

40 As methods for creating the process flow graph, there are a method in which it is described with graphical 

symbols by using a graphics editor, and converted to a text representatfon, and a method in which it is directly 
described with character codes by using a text editor. The created process flow graph is also called a process 
flow program. 

In the embodiment the user describes it interactively with a graphics editor. Figure 7 shows a graphical 
45 representation of the process flow program. A unit of control on the process flow graph is called a task, which 
corresponds to a program file (see Figure 8). 

An example of execution according to the definition of the process flow graph is explained by referring to 
Figure 7. A token is generated in a condition gate or C4. In a case where the token is generated in the con- 
dition gate Ci, the token moves to task places T, and T2 where tasks Ti and T2 are executed by using resources 
so R^ and Rb. When both tasks T, and T2 are completed, the token moves to a task place T3 according to the 
condition of the condition gate C2. The task T3 is executed by using the resource Rb- Then, when the task T3 
is completed, the token moves from the place T3 to the conditfon gate C3, and is removed. In a case where 
the token is generated in the condition gate C4, the token moves to a task place T4 where the task T4 executed 
by using the resource Ra- When the task T4 is completed, the token moves to a task place T5 according to the 
55 condition of the condition gate Cs. The task Ts is executed by using the resources R^ and Rb- Then, when the 
task T5 is completed, the token moves from the place T5 to the condition gate C3. and is removed. This example 
of execution does not contain the mutual exclusive resource control. Here, the condition gate corresponds to 
the transition in the Petri-Net, but definitely differs from the transition in the point that it allows a token to l>e 
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assigned to itself. This will be explained in detail later. 

Atext representation of the process flow program is created In the form of intermediate codes of the process 
flow graph. It is equivalent to the graphical representation, and they can be converted to each other. In the 
following, the text representation of the graph is also called the intermediate codes. 
5 The format of the intermediate codes of the process flow graph is as follows: 

Condition gate: 

Input placed input place ...)/ 
Output place (, output place ...) 
The intermediate codes of the embodiment in Figure 7 is as follows. 
10 Ci:yTi.T2 
Cz : Ti. T2/T3 

C5:T4rr5 

IS Ce : T5/ 

(b) Generation of resource management graph (steps S2 and S3) 

A resource management graph is generated from the process flow graph and the task program. Resource 
20 names of critical resources necessary for the tasks are extracted from the task programs, thereby generating 
a list of them. As shown In Figure 8, when the task program is described in a text, the critical resources described 
therein are described by logical symbols of the resources, logical numbers of the resources, or logical names 
of the resources. A resource management graph is generated from the process flow graph and the list which 
extracted the resource names. Figure 9 shows a resource management graph generated from the process flow 
25 graph of Figure 7 and the resource name list of the critical resources necessary for the tasks. 

It should be noted that, as shown in Figure 8, the user is never required to pay attention to resource man- 
agement by using semaphores or the like, in creating a program of a process flow graph describing connection 
between tasks, or a task program describing an individual task. 

In the embodiment, the program is described with an object oriented language by using a text editor in the 
30 following fonmat 

Logical name of resource : command 

A list is created that extracts the names of the critical resources used by the task from the logical names 
of critical resources in the task programs. A resource management graph is generated from the list and the 
process flow graph. 

35 If the form at of the intermediate codes of the resource management graph is made the sanr^e as that of 

the intermediate codes of the process flow graph, the intermediate codes for the emt>odiment of Figure 9 is 
as follows: 

Ci : /Ra, Rb 
C2 ' Ra» Rb^Rb 
40 C3: Rb/ 

C4:/Ra 
C5 : Ra/Rap Rb 
Ce ; Ra, Rb/ 

Figure 10 is a flowchart illustrating an algorithm for generating such intermediate codes from the process 
45 flow graph with the resource name list If all resources are critical, the resource name list may be created by 
automatically extracting all resource names contained in the task program. The user may create the resource 
name list by specifying the critical resource names. 

(c) Generation of process resource graph (steps S4, S5, and S6) 

50 

The process for generating the process resource graph is shown in Figure 11 as a flowchart. Explanation 
is made by referring to the flowchart The process flow graph and the resource management graph are loaded 
(steps 111 and 112). from which a graph of union is generated (step 113). 

Figure 12 shows graph of union generated from the process resource graph of Figure 7 and the resource 
55 management graph of Figure 9. 

If the form at of the intermediate codes of the unfon graph is made the same as that of the intermediate 
codes of the process flow graph, the representation of the union graph of Figure 12 is as follows: 

Ci : /Ti, T2, Ra» Rb 

6 



EP0 383 506 B1 



^2 • T21 Rai Rb^3« Rb 
C3 I T3, Rq/ 

C4 : /T4, Ra 
C5 : T4, Ra/Ts, Ra, Rb 
5 Ce : T5, Ra, Rb^ 

Figure 1 3 is a flowchart illustrating an algorithm for generating such intermediate codes from the process 
flow graph and the resource management graph. That is. it shows the step 113 of Figure 11 in detail. 

By the way, if the union graph thus generated Is unconditionally regarded as a process resource graph as 
it is, a deadlock may be caused. 
10 Figure 14 shows a case where a deadlock is caused. In the Initial state, a token is in the conditton gate 

Ci. The deadlock is caused because the task Ti should be executed while using the resource Ra, and the task 
T2 should be executed while using the resources Ra and Rg. 

The embodiment uses a graph that causes no deadlock of a common connection graph as the process 
resource graph. When executk>n is performed according to this, it is possible to simultaneously perform the 
15 control of an event driven process and the mutual exclusive resource control. If the common connectton graph 
causes a deadlock, it is reported to the user. 

In the embodiment, the deadlock that may be caused in the common connectton graph is displayed (step 
115) after checking a deadlock at the time when the comnwn connection graph is generated from the process 
flow graph and the resource management graph (step 114). 
20 Figure 15 is a representation of Figure 14 in the form of a union graph. As shown in Figure 15. a deadlock 

occurs in a case where a condition gate and a resource place are connected in duplicate. It is sufficient to check 
whether or not the generated union graph has a resource connected to one conditksn gate in duplicate, and to 
point it out to the user if there is one. If no deadlock occurs, the union graph is used as the process resource 
graph as it is (step 116). 

25 Here, the deadlock referred to herein is not caused from the graph representation described with respect 

to Figure 6 and from the responsibility of the system that performs control according to it As described later, 
occurrence of the deadlock as in Figure 6 is avoided according to the invention. The deadlock displayed in 
step 11 5 of Figure 1 1 is caused from the program structure itself, which should be avoided on the responsibility 
of the user (step 117^. 

30 The process resource graph is a bipartite directed graph, nodes of which are event places and condition 

gates, and arcs of which are input functions and output functions. Marking means to assign tokens to the task 
places, the resource places, or the conditk>n gates of the process resource graph. In addition, at most one token 
can exist in one task place, one resource place, or one condition place. In a conventional Petri-Net a token is 
not assigned to a condition gate, while assigned in the process resource graph. Refer to the "Mathematical 

35 Representation" for the definition of the process resource graph. 

In the union graph or the process resource graph shown in Figure 12, every task node is arranged in parallel 
with a resource node. However, some tasks never access the critical resource. Of course, no resource node 
is arranged in parallel with such a task node (see Figure 18). 

40 (d) Execution of process resource graph (steps S7 and S8) 

The process resource graph is converted into codes for a controller that performs event driven control to- 
gether with the mutual exclush^e control of sequentially available resources, and loaded in the memory or ROM 
of a controller to be executed (such as a computer or a programmable logic controller). When this graph is 

45 executed, the mutual exclusive control and the event driven process control are simultaneously performed. 
For example, a node (an event place ora condition gate) of a process resource graph is implemented In a menv 
ory as a data structure, and the connection between elements is represented by pointers. Information relating 
to presence of a token is stored in the data structure. The method itself for generating or erasing a token is 
implemented similarly to the system of the above reference (2). and is not described in detail herein. 

50 The conditfons for transferring the token presented by the invention are strictfy represented by equations 

(1) and (2). which will be represented by words as follows: 

(I) As soon as the beginning of execution of a task is instructed, a token is assigned to the place (node) 
of the task and the resource place in parallel with the place. That is. according to the invention, different 
from the conventional Petri-Net the token placed in the resource place indicates that the resource is ap- 

55 propriated by the task being executed. 

(II) If there are tasks controlled in parallel, the tokens are transferred to a succeeding condition gate at the 
time when execution of all the tasks is completed. 

(III) While a token is assigned to at least one of the task places immediately after the condition gate and 
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the resource place in parallel with the task places, the beginning of the execution of the succeeding task 
is caused to wait by keeping the token In the condition gate. 

Figure 16 shows the execution according to the definition of the process resource graph of Figure 12 as 
an example of execution control. In Figure 12, there is a case where a token is generated first in the condition 

5 gate C^. and a case where it is generated first in the condition gate C4. This example of execution treats the 
case where the token is generated first in the condition gate Ci. The token is generated in the condition gate 
Ci (Figure 16A). As shown, even if it is necessary to execute the task Ti and T2, tokens are not immediately 
placed in the places T^ and T2. First, the token is assigned to the condition gate Ci. The token moves from the 
condition gate Ci to the task places T, and T2. and the resource place Ra and Rb according to the transfer 

10 condition equation (1) (Figure 16B). At this moment, even if a token is assigned to another conditfon gate, the 
transfer condition equation (1) is not satisfied because a token is assigned to the resource places Ra and Rb- 
Therefore, the token does not move, and a new task other than Ti and T2 is not executed. When both tasks 
Ti and T2 are completed, the token moves from the task places T, and T2 and the resource places R^ and Rb 
to the condition gate C2 according to the transfer condition equation (2) (Figure 16C). In addition, the token 

15 moves from the condition gate C2 to the task place T3 and the resource place Re (Figure 1 6D). At this moment, 
it is assumed that a token is generated in the condition gate C4. The execution of the task T4 can now be started. 
That is, because there is no token in the resource place Ra. the transfer condition equation (1) is satisfied so 
that the token is transferred to the task place T4 and the resource place Ra (Figure 16E). Therefore, the exe- 
cution of the task T3 using the resource Rg and the execution of the task T4 using the resource RAare performed 

20 independently. When T4 is completed, the token moves from the task place T4 and the resource place Ra to 
the condition gate Cs (Figure 16F). Even if a token is assigned to the condition gate C5, the token is not trans- 
ferred from the condition gate Cg to the task place Ts and the resource places Ra and Rb. because another 
token already is assigned to the resource place Rg and the transfer condition equation (1) is not satisfied. That 
is, the task Ts is not executed. When the task T3 is completed, the token moves from the task place T3 and the 

25 resource place Rb to the condition gate C3 according to the transfer condition equation (2), and is removed. 
Therefore, the task T5 becomes executable. 

As seen from the example of Figure 12, the process resource graph becomes a graph having self loops 
with respect to the resource places Ra and Ra- When it is regarded as a restricted Petri-Net with a safe and 
active nature, if tasks attempt to sequentially and immediately use the same resource, a deadlock occurs. For 

30 example, in Figure 12. if. the task T5 attempts to perform execution using the resources Ra and Rb after the 
task T4 completes execution using the resource Ra. a graph of a self loop with respect to the resource Ra is 
constituted, and a deadlock is caused because the transfer condition equation (O), which is described later, 
is never satisfied. 

This will be further described. First, it should be noted that the graph representation like Figure 12 itself 

35 is novel. (Differences from a conventional Petri-Net will be explained in more detail by comparing Figures 6 
and 1 8 later). Then, it is assumed that a token is placed in a place of a held resource, but not placed in a condition 
gate in an embodiment In this example, a token is placed in the places T4 and Ra during execution of the task 
T4. Then, even if the control system attempts to begin the execution of the task T5, that is, even if it attempts 
to transfer a token from the place T4 to the place T5 and the places Ra and Rb, it is impossible to transfer the 

40 token to the place T5 because a token is already assigned to the place Ra- Then, as long as the token cannot 
move to the place T5, the token in the place Ra cannot be removed. 

If a token is caused to exist in a condition gate as defined for the process resource graph, deadlock as in 
the restricted Petri-Net with safeness and liveness never occur. That is, in the above example, at the time when 
the execution of the task T4 is completed, a state where no token is assigned to the place Ra appears by re- 

45 moving the token from places T4 and Ra. and by generating a token in the condition gate C5, so that the token 
can be transferred from the condition gate Cg to the places Tg, Ra. and Rb- That is, the execution of the task 
Tg can be started. The significance of assigning a token to a conditton gate lies in this point 

The executable codes of the process resource graph are loaded in the memory or ROM of the controller 
to be executed. Here, sequentially available resources to be controlled are ones that are controlled by a com- 

50 puter or a programmable logic controller (PLC). These resources include not only those actually contained in 
the controller, but also those that can be controlled through communication or the like. The invention performs 
the mutual exclusive resource control together with the event driven process control for the sequentially avail- 
able resources, which are the objects of the control, based on the executable codes of the process resource 
graph. Figure 1 7 shows an example of hardware configuration of a system that performs such control by load- 

55 ing the executable codes of the process resource graph. In this example, the production apparatus 1. 2, 3, ... 
are the critical resources. A task using such apparatus is described in a task program as shown in Figure 8. A 
signal instructing beginning of the execution of the program and an end signal notifying completion of the exe- 
cution of the program are transferred between the PLC and the production apparatus through a digital in- 
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put/output interface or a communication interface. The completion of execution of a task is detected by sending 
a signal from the production apparatus to the PLC. Otherwise, the PLC may monitor a state of the production 
apparatus to detect change of the state to the completion state. 

In addition, a task program may be stored in the production apparatus, or may be stored in the memory 
5 of the PLC for sequential transfer of instructions from the PLC to the production apparatus. 

Finally, as a summary, the process resource graph that is a result of representatfon of the flow of process 
as shown in Figure 6 according to the invention is shown in Figure 1 8. and an example of its execution is shown 
in Figures 19A through 19D. 

The graph of Figure 18 differs from that of Figure 6 significantly in the following points. Even when two 
10 consecutwe tasks (for example. Pj and P3) use a resource (in this case. PJ. the resource place is connected 
to each of them in parallel. Relations between the input and the output are reversed. For example, in Figure 
6. the place P^ is connected to the Input of the transition t,, while, in Figure 18, it is connected to the output of 
the condition gate Ci. 

Now. an example of execution is discussed wherein a token is transferred according to the invention. First. 

15 it is assumed that tokens are generated in the condition gates Ci and C4 (Figure 1 9A). If there is no token in 
either of the resource places Px and Py. the token can be transferred from the condition C^ the places P2 and 
Px. while from the condition gate C4 to the places P5 and Py (Figure 19B). That is. the execution of the tasks 
P2 and P5 is started. Then, it is assumed that the execution of the task P2 is completed. At this time, the control 
system erases the tokens in the places P2 and Px. and generates a token in the conditton gate C2 (Figure 19C). 

20 At the moment, because a token still is assigned to the place Py, it is impossible to transfer the token to the 
place P3. Thus. In the process A. the token remains in the condition gate C2. and waits for release of the re- 
source Py. Then, when the control system receives an end signal of the task Pg, it removes the token from 
places Ps and Py, and generates a token in the condition gate Cs (Figure 1 9D). The control system may transfer 
the token to the places P3. and Px and Py, or may transfer the token to the places Pe and Px- That is, it can 

25 instruct the beginning of the executton of the task P3 or Pg. As described, deadlock as in Figure 6 never arises. 

As above, the inventfon is explained by refening to the embodiment Other modifications is possible. For 
example, although, rn the above embodiment, the process flow graph and the resource management graph 
are generated in a form of intermediate codes, and the process resource graph is once generated in the form 
of intermediate codes and then converted into executable codes, the form of their representation is not restrlct- 

30 ed to a specific one because it \s sufficient for these graphs to generate in a memory representations equivalent 
to the ones represented in the drawings. 

A description is given according to the definition of the process flow theory in the following. The process 
flow graph Gpfr is: 

GpF = (T, C. h-. Or, tt) 

35 wherein: 

T = ffi. T2 Tm). M > 0 Set of task places 

C = {Ci, C2. .... Cl). L > 1 Set of conditton gates 
T n C = 4> The set of the task places and the set of the condition gates are disjoint. 
It : T C Input function from a task place to a condition gate 
40 Ot : C T Output function from a condition gate to a task place 
p. : T {0, 1} Marking functton of a task place 

A transfer condition equation of a token from a task place T, to To in respect to an arbitrary condition gate Ck 
at an arisitrary time t is: 

45 



ml m2 
#(Ti, To) (t) = n (Ti(t)) _ n ^1 (To(t)) (0) 
1=1 0=1 

wherein, ml > 0. m2 > 0 

A new marking at time t+1 is: in the task place Ti, 

fn(t + 1)) = ^ (Ti(t)) - #(Ti. To) (t) i = 1 ... ml 

in the task place To, 

^ (To(t+ 1)) = ji (To(t)) + #(Ti. To) (t) o = 1 ... m2 
d 
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A token is generated in a case where there is no Input function \j in the condition gate C|c. and the right hand 
terms of the transfer conditfon equation are made: 

ml 

5 

n ^ (Ti(t)) = 1 

i=l 

10 A token disappears in a case where there is no output function Or in the condition gate Ck, and the right hand 
terms of the transfer conditbn equation are made: 



IS ra2 

n ^ CTo(t)) = \ 
o=l 

20 The process resource graph is described according to the definition of the graph theory. The process resource 
graph Gpr is: 

GpR = {T_R, C. It- Ir. Ot- Or.^t- ^r- mc) 

wherein, 

T = {Ji. T2, TpyJ, M > 0 Set of task places 
25 R = {Ri, R2. Rn}. N ^ 0 Set of resource places 
C = {Ci. C2. CJ. L > 1 Set of condition gates 

T n R C " <|> The set of the task places, the set of resource places and the set of the conditfon gates are 
disjoint 

1^ : T C Input function from a task place to a condition gate 
30 : R c Input function from a resource place to condition gate 

It o Ir = <|) The input function Ij and the input function Ir are disjoint 

Ot : C -> T Output function from a condition gate to a task place 

Or : C R Output function from a conditfon gate to a resource place 

Ot n Or = <|> The output function Ot and the output function Or are disjoint 
35 : T {0. 1} Marking function of the task place jir : R -4^ {0. 1} Marking function of the resource place 

He : C {0, 1) Marking function of the condition gate 

fiT Mc = 4* The marking function ^T . the marking function jir, 

and the marking function \ic are disjoint. 

A transfer condition equation of a token from an arbitrary condition gate Ck to event places T and R at an 
40 afbitrary time t is: 



ra n 

45 #(C, P) (t) = {n ^1 (Ti(t)) _ n (Ri(t)) _ (Ck(t)) 

i=l 3=1 

(1) 

50 

wherein, m > 0, n > 0 

A new marking at time t+1 is: in the condition gate Ck, 

Ji(CK(t+1)) = ji(CK(t)) - #(c.p)(t) 

55 in the task place T, 

(n(t + 1)) = n CTi(t)) + #(c, p) (t) i = 1 ... m, 

in the resource place R, 

^ (Rj(t + 1)) = M (RKt)) + #(c, p) (t) j = 1 ... n. 
10 
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A transfer condition equation of a token to an arbitrary condition gate from event places T and R at an ar- 
bitrary time t is: 



10 



ra n 

#(c, p) (t) = (n ^ (T. (t)) _ n ^ (R (t)) _ (c^ (t)) 

i=l j=l 



(2) 



whierein, m > 0, n > 0 
15 A new marking at time t+1 is: in the condition gate Ck, 

(CK(t + 1)) = n (Ck (t)) + #(p. c) (t) 

in the task place T, 

ji (T,(t + 1)) = n {T,{t)) - #(p. c) (t) i = 1 .„ m, 

in the resource place R, 
20 M(Ri(t+1)) = M(R|(t)) - #(p,c)(t)j = 1 ... n. 

A token is generated in a case where there is no input function ly and Ir in the condition gate C^. and the right 
hand terms of the transfer condition equation (2) are made: 

(n »i. (Ti(t)) _ n M. (It (t)) = 1 

i=l j=l 

30 A token is removed in a case where tliere is no output function and Or in the condition gate Ck, and the 
right hand tems of the transfer condition equation (1) are made: 



(n ji (T.(t)) _ n (R(t)) = 1 
i=l 3=1 

40 The invention enables a user to perform the mutual exclusive control for sequentially available resources 

together with the event driven control only by describing an event driven control (the process flow graph and 
the task program). The invention automatically performs programming and execution for management of re- 
sources in a process, for which a programmer was responsible, and removes the burdens of preventing errors 
in a resource management program from the programmer, and removes the burden of executing the program 

45 from the operator. 

In addltton, the invention provides the advantage that a deadlock which may conventionafly occur in a Petri- 
Net is avoided by assigning a token to a condition gate. 



50 Claims 



1 . A method for mutual exclusive resource control comprising steps of: 

(a) generating a graph and retaining the graph in a storage apparatus, the graph comprising nodes to 
which tasks included in a process flow and a critical resource, which may be appropriated by at least 

55 one of the tasks, are mapped, nodes of tasks executed sequentially being arranged In series, nodes 

of tasks executed in parallel being arranged in parallel with each other, a node of critical resource being 
arranged in parallel with every node of the task that may appropriate the critical resource; and 

(b) each time a signal for beginning execution of a task is transmitted, generating a token in the node 
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of the task and the critical resource node in parallel therewith; and 

(c) when the end of execution of the preceding task in the process flow is detected, referring to said 
graph; and causing the transmission of a signal for beginning execution of the immediately succeeding 
tasks to wait while a token is assigned to at least one of the immediately succeeding task node and 
the critbal resource node arranged in parallel therewith. 

A method as claimed in Claim 1, comprising in said step (a), providing a gate node in said graph at a lo- 
catk>n where nodes of tasks executed sequentially are connected: 

in said step (b), removing tokens from a task node and a critical resource node arranged In parallel 
with it each time the completion of the execution of the task is detected, generating a token in a gate 
node when completion of tasks corresponding to alt the task nodes arranged immediately before the gate 
node is detected, then, referring to said graph, and causing the transmission of a signal for beginning the 
execution of a succeeding task to wait while a token is assigned to at least one of the task node and the 
critical resource node in parallel therewith arranged innmediately after the gate node; and removing the 
token from said gate node after the transmission of the signal for beginning the execution of said suc- 
ceeding task. 

A method as claimed in claim 2. wherein said step (a) comprises; 

(a 1 ) creating a process flow graph consisting of nodes of tasks included in the process flow and nodes 
of gates; 

(a 2) creating a resource management graph consisting of nodes of critical resources, which may be 
appropriated by at least one of said tasks, and nodes of said gates; and 

(a 3) creating a graph of union in which said process flow graph and said resource management graph 
are overlapped with nodes of said gates common, and retaining the graph of union in a storage device. 

A method as claimed in Qalm 3. wherein, after the union graph of the process flow graph and the resource 
graph are created in said step (a 3), said union graph is checked to see whether or not there is a location 
where a deadlock occurs, and displaying the union graph to a user if so. 

A method as claimed in Claim 4, wherein, 

in step (a 1), the process flow graph is outputted in the form of intemriediate codes; 

in step (a 2), the resource management graph is outputted in the form of intermediate codes; 

in step (a 3), the union graph is once outputted in the form of intermediate codes, which are con- 
verted into executable codes and then retain in a storage device; and 

in step (b), mutual exclusive control is performed based on said execution codes. 

A system for mutual exclusive resource control comprising a storage apparatus retaining a graph in which 
tasks included in a flow of process, and critical resources, which may be appropriated by at least one task, 
correspond to nodes, nodes of tasks sequentially executed being arranged in series, nodes of the tasks 
executed in parallel being arranged in parallel with each other, a node of a critical resource being arranged 
in parallel with every node of tasks that may appropriate the critical resource; 

means for generating tokens in a node of a task and a node of a critical resource arranged in parallel 
with the task node in said graph each time a signal for beginning execution of the task is transmitted; 

means for referring to said graph when the end of executfon of a preceding task in the process flow 
is detected, and causing the transmission of a signal for t>eginning execution of the immediately succeed- 
ing tasks to wait while a token is assigned to at least one of the immediately succeeding task nodes and 
the critical resource node arranged in parallel therewith. 

A system as claimed in Claim 6 wherein a node of a gate is arranged in the graph at a location connecting 
the nodes of the tasks with each other, the system comprising means for removing the tokens assigned 
to the node of the task and to the node of the critical resource arranged in parallel with the task node each 
time the end of the execution of the task is detected; 

means for generating a token in a gate node, when completk)n of execution corresponding to all 
the task nodes arranged immediately before the gate node; and 

means for erasing the token in the gate node after the signal for beginning the succeeding task is 
transmitted. 
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Patentanspruche 

1. Ein Verfahren zur gegenseitig ausschlieBenden Betriebsmitteisteuerung. das folgende Schritte umfaRt 

(a) Erzeugen eines Graphen und Festhalten des Graphen in einer Speichervorrichtung, wobei der 
Graph Knoten umfa&t denen Tasks, die in einen ProzeBablauf integriert sind, und ein kritisches Be- 
triebsmittel, das sich mindestens einer der Tasks aneignen kann. zugeordnet sind, die Knoten von se- 
quentiell ausgef uhrten Tasks in Reihe angeordnet sind, die Knoten von parallel ausgefuhrten Tasks par- 
allel zueinanderangeordnetsind und ein Knoten des kritischen Betriebsmittels parallel zu jedem Kno- 
ten des Tasks angeordnet Ist, der sich das kritische Betriebsmittel aneignen kann; und 

(b) bei jeder Obertragung eines Signals fur den Beginn der Ausf uhrung eines Tasks Erzeugen eines 
Balkens in dem Knoten des Tasks und des dazu parallelen Knotens des kritischen Betriebsnnittels; und 

(c) bei der Erkennung des Endes der Ausf uhrung des vorherigen Tasks inn Prozeliablauf ZurOckgreifen 
auf den Graph; und Veranlassen, da& die Obertragung eines Signals fur den Beginn der Ausf uhrung 
der unmrttelt>ar nachfolgenden Tasks wartet. wShrend ein Balken mindestens einem der unmittelbar 
nachfblgenden Taskknoten und dem parallel dazu angeordneten Knoten des kritischen Betriebsmttteis 
zugeordnet ist 

2. Ein Verfahren gemSa Anspruch 1, umfassend in Schritt (a) das Vorsehen eines Gatterknotens an einer 
Stelle des Graphen, an der Knoten der Tasks, die sequenttell ausgefuhrt werden, verbunden sind; 

in Schritt (b) das Entfernen von Balken von einem Taskknoten und einem parallel dazu angeordneten kri- 
tischen Betriebsmittelknoten bei jeder Erkennung der Vollendung der Ausfuhrung des Tasks, das Erzeu- 
gen eines Balkens in einem Gatterknoten bei der Erkennung der Vollendung von Tasks, die zu alien Task- 
Knoten gehoren, die unmittelbar vor dem Gatterknoten angeordnet sind, und dann das Zuaickgreifen auf 
den Graph und das Veranlassen der Obertragung eines Signals zum Beginnen der Ausfuhrung eines 
nachfolgenden Tasks zum Warten, wahrend ein Balken mindestens einem der Taskknoten und dem par- 
allel dazu unmittelbar nach dem Gatterknoten angeordneten kritischen Betriebsmittelknoten zugewiesen 
wird; und das Entfernen des Balkens von dem Gatterknoten nach der Obertragung des Signals zum Be- 
ginnen der Ausf uhrung des nachfolgenden Tasks 

3. Ein Verfahren gemaK Anspruch 2. wobei der Schritt (a) unrtfaBt 

(a 1) das Erstellen ernes ProzeBablaufgraphen, bestehend aus Knoten von Tasks, die in dem ProzeB- 
ablauf enthalten sind, und aus Knoten von Gattern; 

(a 2) das Erstellen eines Betriel>smittelverwaltungsgraphen, bestehend aus Knoten kritischer Betriebs- 
mittel. die sich mindestens einer der Tasks aneignen kann, und aus Knoten derGatter; und 
(a 3) das Erstellen eines Vereinigungsgraphen, in dem der ProzeBablaufgraph und der Betriebsmittel- 
verwaltungsgraph mit Knoten gemeinsamer Gatter uberlappt sind, und das Festhalten des Vereini- 
gungsgraphen in einer Speichervonrichtung. 

4. Ein Verfahren gema& Anspruch 3, bei dem nach dem Erstellen des Vereinigungsgraphen aus ProzeBab- 
laufgraph und Betriebsmittelgraph in Schritt (a 3) der Vereinigungsgraph darauf hin uberpruft wird. ob es 
eine Stelle gibt, an der es zu einer Blockierung kommt, und wenn ja, der Vereinigungsgraph einem Be- 
nutzer angezeigt wird. 

5. Ein Verfahren gemSB Anspruch 4, be! dem 

in Schritt (a 1) der ProzeBablaufgraph in Form von Zwischencodes ausgegeben wird; 

in Schritt (a 2) der Betriebsmittelverwaltungsgraph in Form von Zwischencodes ausgegeben wird; 

in Schritt (a 3) der Vereinigungsgraph einmal in Form von Zwischencodes ausgegeben wird, die rn aus- 

fuhrbare Codes umgewandelt und dann in einer Speichervonichtung festgehalten werden; und 

in Schritt (b) die gegenseitig ausschlieRende Steuerung auf der Grundlage der Ausf uhrungscodes durch- 

gef uhrt wird. 

6. Ein System fur eine gegenseitig ausschlleBende Betriebsmittelsteuerung. die eine Speichervonichtung 
umfaBt, die einen Graph enthalt, in dem Tasks, die in einem ProzeBablauf enthalten sind, und kritische 
Betriebsmittel, die sich mindestens ein Task aneignen kann, zu Knoten gehoren, Knoten von Tasks, die 
sequentiell ausgefuhrt werden, in Reihe angeordnet sind. Knoten der Tasks, die parallel ausgefuhrt wer- 
den. parallel zueinanderangeordnetsind und ein Knoten eines kritischen Betriebsmittels parallel zu jedem 
Knoten von Tasks angeordnet Ist, die sich das kritische Betriebsmittel aneignen konnen; 

ein Mittel zur Erzeugung von Balken in einem Knoten eines Tasks und in einem Knoten eines kritischen 
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Betriebsmittels, der parallel zu dem Taskknoten in dem Graph angeordnet ist, bei jeder Obertragung eines 
Signals zum Beginnen eines Tasks; 

ein Mittel zum Zuruckgreifen auf den Graph bei der Erkennung des Endes der Ausf uhrung eines vorher- 
gehenden Tasks In dem Proze&ablauf und Veranlassen der Obertragung eines Signals zum Beginnen der 
Ausf uhrung der u nmittelbar nachfolgenden Tasks zum Warten, wahrend ein Balken mindestens einem der 
unmittelbar nachfolgenden Taskknoten und dem parallel dazu angeordneten kritischen Betriebsmittelkno- 
ten zugewiesen wird. 

7. Ein System gemaB Anspruch 6, in dem ein Knoten eines Gatters an einer Stelle des Graphen angeordnet 
ist die die Knoten der Tasks miteinander verbindet. wobei das System unnfaBt ein Mittel zum Entfernen 
der Balken, die dem Knoten des Tasks und dem parallel zu dem Taskknoten angeordneten Knoten des 
kritischen Betriebsmittels zugewiesen sind. bei jeder Erkennung des Endes der Ausf uhrung des Tasks; 
ein Mittel zum Erzeugen eines Balkens in einem Gatterknoten, wenn die Ausf uhrung, die zu alien unmit- 
telbar vor dem Gatterknoten angeordneten Taskknoten gehort, beendet ist; und 

ein Mittel zum Loschen des Balkens in dem Gatterknoten nach der Obertragung des Signals zum Begin- 
nen des nachfolgenden Tasks. 

Revendicatlons 

1 . Proc6d6 pour la commande de ressource mutuellement exclusive comprenant les Stapes conststant ^ : 

(a) g6n6rer un graphe et conserver le graphe dans un appareil de m6morisation, le graphe comprenant 
des noeuds sur lesquels des tdches comprises dans un dSroulennent de processus et une ressource 
critique, qu'au moins une des tdches |>eut s'approprier, sont planif iSes, les noeuds des tSches exScu- 
t^es sSquentiellement Stant agencSs en series, les noeuds de tdches exScutSes en parall&le Stant 
agenc6s en parallSle les uns avec les autres, un noeud de ressource critique Stant agencS en parallSle 
avec chacun des noeuds de la tSche qui peut s'approprier la ressource critique, et 

(b) d chaque fbis qu'un signal de d^but d'exScution d'une tSche est transmis, g§n6rer un jeton dans le 
noeud de la tSche et le noeud de ressource critique en parall^le avec celuh-d, et 

(c) lorsque la fin de I'exScutlon de la tSche pr6c6dente dans le ddroulement du processus est dStectSe, 
se r6f6rer audit graphe, et provoquer la transmission d'un signal de dSbut d'exdcution des tdches im- 
m§diatement suivantes en attente alors qu'un jeton est affects k au moins un parmi le noeud de t§che 
suivant imm6diatement et le noeud de ressource critique agenc6 en parallfele avec celui-ci. 

2. Proc6d6 selon la revendicatton 1, comprenant dans ladite 6tape (a), Tapprovisionnement d'un noeud de 
porte dans ledit graphe d un emplacenr^nt oCi les noeuds des tSches exdcutSes sSquentiellement sont 
reiiSs : 

dans ladite §tape (b), la suppression des jetons provenantd'un noeud de tSche et d'un noeud de ressource 
critique agencS en paralldle avec celui-ci, k chaque fois que I'achfevement de TexScution de la tSche est 
d6tect6, la g6n6ration d'un jeton dans un noeud de porte lorsque Tachfevement des tSches correspondant 
d tous les noeuds de tSche agenc6s Imm6diatement avant le noeud de porte soit d6tect6, puis, la consul- 
tation dudit graphe et le dSdenchement de la transmission d'un signal de d6but d'ex6cution d'une tSche 
suivante en attente alors qu'un jeton est affects ^ au moins un parmi les noeuds de tSche et le noeud de 
ressource critique en parall^le avec celui-ci agencS imm6diatement apr^ le noeud de porte. et la sup- 
pression du jeton dudit noeud de porte apr^ la transmission du signal de dSbut d'exScution de ladite tSche 
suivante. 

3. Proems selon la revendlcation 2, dans lequel ladite Stape (a) comprend. 

(a 1} la cr^tion d'un graphe de dSroulement de processus consistant en des noeuds de tdches Indus 
dans le d6roulement de processus et des noeuds de portes. 

(a 2) la cr6atk>n d'un graphe de gestion de ressource consistant en des noeuds de ressources critiques, 
qu'au moins une desdites tdches peut s'approprier. et de noeuds desdites portes, et 
(a 3) la creation d'un graphe d'union dans lequel ledit graphe de d6roulement de processus et ledit gra- 
phe de gestion de ressource se recouvrent avec des noeuds desdites portes en commun. et la conser- 
vation du graphe d'union dans un dispositif de mSnrK>risation. 

4. Proc6d6 selon la revendlcation 3, dans lequel aprfes que le graphe d'union du graphe de d6roulement de 
processus et que le graphe de ressource soient cr66s dans ladite Stape (a 3), ledit graphe d'union est 
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v6rif i6 pour voir s'il existe ou non un emplacement ou se produit un blocage. et en affichant te graphe 
d'union ^ un utilisateursi c'est le cas. 

Proc^6 selon la revendtcation 4, dans lequel, 

dans r^tape (a 1), le graphe de d6roulementde processus est sorti sous la forme de codes intermedia ires, 

dans r6tape (a 2), le graphe de gestion de ressource est sorti sous la fbmie de codes interm^diaires. 

dans retape (a 3), le graphe d'union est sorti une fois sous la forme de codes intemi6diaires. qui sont 

convertis en codes ex6cutables purs conserves dans un disposttif de mdnrorisation. et 

dans r6tape (b). la connmande nrtutuellement exclusive est effectu6e sur la base desdits codes d'ex6cu- 

tion. 

Systdme destine d la commande de ressource mutuellement exclusive comprenant un appareil de me- 
morisation conservant un graphe dans lequel les t§ches inciuses dans un d§roulement de processus, et 
des ressources critiques, qu'au moins une tSche peut s'approprier. conwpondent ^ des noeuds, les 
noeuds des t§ches ex^cut^es s6quentiellement 6tant agenc6s en series, les noeuds des tSches exkcu- 
t6es en parall^le 6tant agenc6s en paralieie les uns avec les autres. un noeud d'une ressource critique 
6tant agenc6 en paralldle avec chaque noeud des tdches qui peuvent s'appre)prier la ressource critique, 
un moyen destine d g6n6rer des jetons dans un noeud d'une tSche et un noeud d'une ressource critique 
agenc6 en paralieie avec le noeud de t§che dans ledit graphe d chaque fois qu'un signal de d6but d'ex6- 
cution de la tdche est transmis, 

un moyen pour se r^f^rer audit graphe lorsque la fin de rex6cution d'une t§che pr6cedente dans le d6- 
roulement de processus est d6tectee, et pour provoquer la transmission d'un signal de d6but d'ex6cution 
des tSches tmmediatement survantes en attente aiors qu'un jeton est affecte d au moins un parm! les 
noeuds de tSche imm6diatement suivants et le noeud de ressource critique agenc6 en paralieie avec 
ceux-ci. ^ 

Systeme selon la revendicatlon 6 dans lequel un noeud d'une ports est agenc6 dans le graphe k un em- 
placement reliant les noeuds des tSches entre elles. le systfeme comprenant un moyen pour supprimer 
les jetons affectes au noeud de la tSche et au noeud de la ressource critique agenc6 en paralieie avec 
le noeud de tSche ^ chaque fois que la fin de Texecution de la tSche est d6tect6e. 
un moyen de generation d'un jeton dans un noeud de porte. iors de I'achevement de Texecution corres- 
pondent e tous les noeuds de tSche agences immediatement avant le noeud de porte. et 
un moyen d'effacement du jeton dans le noeud de porte aprds que le signal de debut de la tSche suivante 
soit transmis. 
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FIG. 3A 



PROGRAM FOR CONTROLUNG FLOW 



Program Haln 
begin 

while -END do 
begin 

if (tl is Okay) then 
begin 

with robot2 do 
begin 

R2 ( pi ); 
end 

end 

if Ct2 is Okay) then 
begin 

with robot 1 do 
begdLn 

Rl C p2 ); 
end 

end 

if (t4 is Okay) then 
begin 

with ( robot 1, robot2 ) do 
begin 

Rl ( p31 ); 
R2 ( p31 ); 
Rl ( p32 ); 
R2 C p32 ): 
Rl C p33 ); 
R2 ( p33 ): 
end 

end 

if (t6 is Okay) then 
begin 

with ( robot 1, robot2 ) do 
cobegin 

R2 ( p4 ); 
Rl ( p5 ); 
coend 

end 

end 

end 
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FIG. 3B 



PROGRAM FOR ROBOT 1 



Prograa Rl ( p ) 
begin 

case C p ) 
p2: 
begin 

SPEEDCSOD; 

OPENC); 

DELAY(2); 

MO VE( B CSTATU , B CSTATD ) ; 

CLOSEO; 

DELAY(2); 

MOVE(BCSTATU); 

IF A = 0 THEN MOVECALTBLUO.ALTBLDO); 
IF A = 1 THEN M0VECALTBUJI,ALTBLD1); 
IF A = 2 THEN MOVE( ALTBLU2,ALTBLD2); 
OPENC); 
DELAy(2); 

IF A = 0 THEN ttOVECALTBLUO); 
IF A = 1 THEN MOVECALTBLUl); 
IF A = 2 THEN flOVE( ALTBLU2); 
A := A + 1; 
end 
p3L: 
begin 

SPEED(50); 
OPENC); 
DELAY(2); 
MOVECPPASSB); 
end 
p32: 
begin 

MOVECPPASSF); 
CLOSEC ); 
DELAYC2); 
end 
p33: 
begin 

MOVE C PP AS S B , DSPOSU , DSPOSD ) ; 
OPENC); 

MOVE ( DSPOSU , ALTB LUG ) ; 
end 
pA: 
begin 

SPEEDC50); 

OPENC); 

A : = A - 1; 

IF A < 0 THEN A :=» 0; 

IF A = 0 THEN MOVECALTBLUO,/LTBU)0); 

IF A « 1 THEN MOVECALTBLUl, ALTBLDI); 

IF A = 2 THEN MOVEC ALTBL02,ALTBLD2); 

CLOSEC); 

DELAYC2); 

IF A = 0 THEN MOVECALTBLUO); 
IF A = 1 THEN MOVECALTBLUl); 
IF A = 2 THEN M0VECALT3LU2); 
MOVECBCSTAtU); 
MOVECBCSTATD); 
OPENC); 
DELAyC2); 
MOVZ(BCSTATO); 
MOVECALTBLUO); 
end 

end 

end 
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FIG. 3C 

PROGRAM FOR ROBOT 2 



Program R2 ( p ) 
bcgdla 

case C p ) 

begin 
OPENC); 
ARM(LEFT); 

MOVEC FRNTSTATU,rRKTSTATD) ; 

CLOSEC); 

DELAY(8); 

HOVE(FRNTSTATU); 

ARM( RIGHT); 

MOVE( SBCSTATU , SBCSTATD) ; 
OPENC); 
DELAYC8); 
MOVE(SBCSTATU); 
ttOVECCOTTBLUO); 
end 
p31: 
begxn 

ARM(LEFT); 

OPENC): 

DELAY(a); 

MOVEC FRNTSTATU , TRI^STATD ) ; 

CLOSEC); 

DEI-AYCS); 

MOVEC FRNTSTATU); 

ARMC RIGHT); 

MOVEC CrnXBUJO , SPASS) ; 
end 
p32: 
begin 

OPENC); 

DELAYCB); 
end 
p33: 
begin 

MOVEC ClfTTBLOO); 
end 
p4: 

begin 

OPENC); 

ARMC LEFT); 

MOVEC FRNTSTATU , FRNTSTATD ) ; 

CLOSEC); 

DELAYC8); 

MOVEC FRNTSTATU) ; 

IF A = 0 THEN MOVEC CNTTBLUO.CNrrBLDO); 
IF A = 1 THEN MOVEC CJnTBLUl,anTBLDl); 
IF A = 2 THEN M0VECCNrrBLU2,CNTTBLD2); 
A := A + 1; 
OPENC); 
DELAYCS); 
MOVEC CNTTBLUO): 
end 

end 
end 
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TASK PROGRAM : IRAN 



PROCESS FLOW 
GRAPH :MAIN 



R0B0T1: 


MC>/EIP0SI_6); 


R0B0T2: 


M0VE(P0SI_7); 


R0B0T2. 


CLOSE; 


R0B0T1 • 


OPEN : 


R0B0T2 


:M0VE(P0S_8): 


R0BOT1 


.M0VE(P0S_9); 


R0B0T2 


:MOVE(POS_10): 
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/ 
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FIG. 8 
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